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1  Introduction 

The  purpose  of  a  computer  system  requirements  specification  is  to  describe  the 
computer  system’s  required  external  behavior.  To  avoid  overspecification,  the 
requirements  specification  should  describe  the  system  behavior  as  a  mathemat¬ 
ical  relation  between  entities  in  the  system’s  environment.  When  some  of  these 
entities  are  continuous  and  others  are  discrete,  the  system  is  referred  to  as  a 
“hybrid”  system. 

Although  computer  science  provides  many  techniques  for  representing  and 
reasoning  about  the  discrete  quantities  that  affect  system  behavior,  practical 
approaches  for  specifying  and  analyzing  systems  containing  both  discrete  and 
continuous  quantities  are  lacking.  The  purpose  of  this  paper  is  to  present  a  for¬ 
mal  framework  for  representing  and  reasoning  about  the  requirements  of  hybrid 
systems.  As  background,  the  paper  briefly  reviews  an  abstract  model  for  specify¬ 
ing  system  and  software  requirements,  called  the  Four  Variable  Model  [12],  and 
a  related  requirements  method,  called  SCR  (Software  Cost  Reduction)  [10,  1]. 
The  paper  then  introduces  a  special  discrete  version  of  the  Four  Variable  Model, 
the  SCR  requirements  model  [8]  and  proposes  an  extension  of  the  SCR  model 
for  specifying  and  reasoning  about  hybrid  systems. 

2  Background 

2.1  The  Four  Variable  Model 

The  Four  Variable  Model,  which  is  illustrated  in  Figure  1,  describes  the  required 
system  behavior  as  a  set  of  mathematical  relations  on  four  sets  of  variables — 
monitored  and  controlled  variables  and  input  and  output  data  items.  A  moni¬ 
tored  variable  represents  an  environmental  quantity  that  influences  system  be¬ 
havior,  a  controlled  variable  an  environmental  quantity  that  the  system  controls. 
Input  devices  (e.g.,  sensors)  measure  the  monitored  quantities  and  output  de¬ 
vices  set  the  controlled  quantities.  The  variables  that  the  devices  read  and  write 
are  called  input  and  output  data  items. 

The  four  relations  of  the  Four  Variable  Model  are  REQ,  NAT,  IN,  and  OUT. 
The  relations  REQ  and  NAT  provide  a  black  box  specification  of  the  required 


Report  Documentation  Page 

Form  Approved 

OMB  No.  0704-0188 

Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 

VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number. 

1.  REPORT  DATE 

1996 

2.  REPORT  TYPE 

3.  DATES  COVERED 

00-00-1996  to  00-00-1996 

4.  TITLE  AND  SUBTITLE 

5a.  CONTRACT  NUMBER 

Requirements  Specifications  for  Hybrid  Systems 

5b.  GRANT  NUMBER 

5c.  PROGRAM  ELEMENT  NUMBER 

6.  AUTHOR(S) 

5d.  PROIECT  NUMBER 

5e.  TASK  NUMBER 

5f.  WORK  UNIT  NUMBER 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Naval  Research  Laboratory, Code  5546,4555  Overlook  Avenue, 

SW, Washington, DC, 20375 

8.  PERFORMING  ORGANIZATION 

REPORT  NUMBER 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

10.  SPONSOR/MONITOR'S  ACRONYM(S) 

11.  SPONSOR/MONITOR'S  REPORT 
NUMBER(S) 

12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited 

13.  SUPPLEMENTARY  NOTES 

14.  ABSTRACT 

15.  SUBIECT  TERMS 

16.  SECURITY  CLASSIFICATION  OF: 

17.  LIMITATION  OF 
ABSTRACT 

18.  NUMBER 

OF  PAGES 

11 

19a.  NAME  OF 
RESPONSIBLE  PERSON 

a.  REPORT 

unclassified 

b.  ABSTRACT 

unclassified 

c.  THIS  PAGE 

unclassified 

Standard  Form  298  (Rev.  8-98) 

Prescribed  by  ANSI  Std  Z39-18 


Fig.  1.  Four  Variable  Model. 


system  behavior.  NAT  describes  the  natural  constraints  on  system  behavior — 
that  is,  the  constraints  imposed  by  physical  laws  and  by  the  system  environment. 
REQ  defines  the  system  requirements  as  a  relation  the  system  must  maintain 
between  the  monitored  and  the  controlled  quantities. 

One  approach  to  describing  the  required  system  behavior,  REQ,  is  to  specify 
the  ideal  system  behavior,  which  abstracts  away  timing  delays  and  imprecision, 
and  then  to  specify  the  allowable  system  behavior,  which  bounds  the  timing 
delays  and  imprecision.  Typically,  a  function  specifies  ideal  system  behavior, 
whereas  a  relation  specifies  the  allowable  system  behavior.  The  allowable  system 
behavior  is  a  relation  rather  than  a  function  because  it  may  associate  a  monitored 
variable  with  more  than  a  single  value  of  a  controlled  variable.  For  example,  if 
the  system  is  required  to  display  the  current  water  level,  it  may  be  acceptable 
for  the  displayed  value  of  water  level  at  time  t  to  deviate  from  the  actual  value 
at  time  t  by  as  much  as  0.1  cm. 

The  system  requirements  are  easier  to  specify  and  to  reason  about,  if  the  ideal 
behavior  is  defined  first..  Then,  the  required  precision  and  timing  can  be  speci¬ 
fied  separately.  This  is  standard  engineering  practice.  Moreover,  this  approach 
provides  an  appropriate  separation  of  concerns,  since  the  required  system  timing 
and  accuracy  can  change  independently  of  the  ideal  behavior  [3]. 

The  relation  IN  specifies  the  accuracy  with  which  the  input,  devices  measure 
the  monitored  quantities  and  the  relation  OUT  specifies  the  accuracy  with  which 
the  output,  devices  Sj“t.  the  controlled  quantities.  To  achieve  the  allowable  system 
behavior,  the  input,  and  output,  devices  must,  measure  the  monitored  quantities 
and  set.  the  controlled  quantities  with  sufficient,  accuracy  and  sufficiently  small 
timing  delays.  In  the  Four  Variable  Model,  the  software  requirements  specifica¬ 
tion,  called  SOFT,  defines  the  required  relation  between  the  input,  and  output 
data,  items.  SOFT  can  be  derived  from  REQ,  NAT,  IN,  and  OUT. 

2.2  SCR  Requirements  Specifications 

The  SCR  requirements  method  was  introduced  in  1978  with  the  publication  of 
the  requirements  specification  for  the  A- 7  Operational  Flight.  Program  [10,  1]. 
Since  its  introduction,  the  method  has  been  extended  to  specify  system  as  well 
as  software  requirements  and  to  include,  in  addition  to  functional  behavior,  the 
required  system  timing  and  accuracy  [12,  13,  14].  Designed  for  use  by  engineers, 


Fig.  2.  Requirements  Specification  for  Safety  injection. 


the  SCR  method  has  been  successfully  applied  to  a  variety  of  practical  systems, 
including  avionic  systems;  a,  submarine  communications  system  [9];  and  safety- 
critical  components  of  a  nuclear  power  plant  [14].  More  recently,  a  version  of  the 
SCR  method  called  GoRE  [4]  was  used  to  document  requirements  of  Lockheed’s 
C-130J  Operational  Flight  Program  (OFF)  [5].  The  OFP  consists  of  more  than 
lOOIv  lines  of  Ada  code,  thus  demonstrating  the  scalability  of  the  SCR  method. 

To  represent  requirements  both  abstractly  and  concisely,  SCR  specifications 
use  two  special  constructs,  called  mode  classes  and  terms.  A  mode  class  is  a 
state  machine,  defined  on  the  monitored  variables,  whose  states  are  called  sys¬ 
tem  modes  (or  simply  modes)  and  whose  transitions  are  triggered  by  changes  in 
the  monitored  variables.  Complex  systems  are  defined  by  several  mode  classes 
operating  in  parallel.  A  term  is  an  auxiliary  function  defined  on  monitored  vari¬ 
ables,  mode  classes,  or  other  terms.  In  SCR  specifications,  conditions  and  events 
are  used  to  describe  the  system  states.  A  condition  is  a  logical  proposition  de¬ 
fined  on  a  single  system  state,  whereas  an  event  is  a  logical  proposition  defined 
on  a  pair  of  system  states.  An  event  occurs  when  a  system  entity  (that  is,  a 
monitored  or  controlled  variable,  a  mode  class,  or  a  term)  changes  value.  A  spe¬ 
cial  event,  called  an  monitored  event ,  occurs  when  a  monitored  variable  changes 
value.  Another  special  event,  called  a  conditioned  event,  occurs  if  an  event  occurs 
when  a  specified  condition  is  true. 

To  illustrate  the  SCR  method,  we  consider  a  simplified  version  of  the  con¬ 
trol  system  for  safety  injection  described  in  [2].  The  system  uses  three  sensors 
to  monitor  water  pressure  and  turns  on  a  safety  injection  system  (which  adds 
coolant  to  the  reactor  core)  when  the  pressure  falls  below  some  threshold.  The 
system  also  displays  the  current  value  of  water  pressure.  The  system  operator 
blocks  safety  injection  by  turning  on  a  “Block”  switch  and  resets  the  system  after 
blockage  by  turning  on  a  “Reset”  switch.  Figure  2  shows  how  SCR  constructs 
are  used  in  specifying  the  requirements  of  the  control  system.  Water  pressure 
and  the  “Block”  and  “Reset”  switches  are  represented  as  monitored  variables, 
WaterPres,  Block,  and  Reset;  safety  injection  and  the  display  as  controlled  vari¬ 
ables,  Saf etylnj ection  and  DisplayPres;  each  sensor  value  as  an  input  data 
item;  and  the  hardware  interfaces  between  the  control  system  software  and  the 
safety  injection  system  and  the  display  output  as  output  data  items. 

The  specification  for  the  control  system  includes  a  mode  class  Pressure,  a 
term  Overridden,  and  several  conditions  and  events.  The  mode  class  Pressure, 


Old  Mode 

Event 

New  Mode 

TooLow 

@T(WaterPres  >  Low) 

Permitted 

Permitted 

@T(WaterPres  >  Permit) 

High 

Permitted 

@T(WaterPres  <  Low) 

TooLow 

High 

@T(WaterPres  <  Permit) 

Permitted 

Table  1.  Mode  Transition  Table  for  Pressure. 


Mode 

Events 

High 

False 

@T(Inmode) 

TooLow, 

@T(Block=0n) 

@T(Inmode)  OR 

Permitted 

WHEN  Reset=0ff 

@T(Reset=0n) 

Overridden 

True 

False 

Table  2.  Event  Table  for  Overridden. 


an  abstract  model  of  the  monitored  variable  WaterPres,  contains  three  modes, 
TooLow,  Permitted,  and  High.  At  any  given  time,  the  system  must  be  in  one  of 
these  modes.  A  drop  in  water  pressure  below  a  constant  Low  causes  the  system 
to  enter  mode  TooLow;  an  increase  in  pressure  above  a  larger  constant  Permit 
causes  the  system  to  enter  mode  High.  The  term  Overridden  denotes  situations 
in  which  safety  injection  is  blocked.  An  example  of  a  condition  in  the  specification 
is  “WaterPres  <  Low” .  Events  are  denoted  by  the  notation  “@T” .  Two  examples 
of  events  are  the  monitored  event  @T(Block=0n)  (the  operator  turns  Block  from 
Off  to  On)  and  the  conditioned  event  @T(Block=0n)  WHEN  WaterPres  <  Low 
(the  operator  turns  Block  to  On  when  water  pressure  is  below  Low). 

SCR  requirements  specifications  use  special  tables,  called  condition  tables, 
event  tables,  and  mode  transition  tables,  to  represent  the  required  system  be¬ 
havior  precisely  and  concisely.  Each  table  defines  a  mathematical  function.1  A 
condition  table  describes  a  controlled  variable  or  a  term  as  a  function  of  a  mode 
and  a  condition ;  an  event  table  describes  a  controlled  variable  or  term  as  a 
function  of  a  mode  and  an  event.  A  mode  transition  table  describes  a  mode 
as  a  function  of  another  mode  and  an  event.  While  condition  tables  define  to¬ 
tal  functions,  event  tables  and  mode  transition  tables  may  define  partial  func¬ 
tions,  because  some  events  cannot  occur  when  certain  conditions  are  true.  For 
example,  in  the  control  system  above,  the  event  @T(Pressure=High)  WHEN 
Pressure=TooLow  cannot  occur,  because  starting  from  TooLow,  the  system  can 
only  enter  Permitted  when  a  state  transition  occurs. 

Tables  1-3  are  part  of  REQ,  the  requirements  specification  for  the  control 
system.  Table  1  is  a  mode  transition  table  describing  the  mode  class  Pressure  as 

1  Although  SCR  specifications  can  be  nondeterministic,  our  initial  model  is  restricted 
to  deterministic  systems. 


Mode 

Conditions 

High,  Permitted 

True 

False 

TooLow 

Overridden 

NOT  Overridden 

Safety  Injection 

Off 

On 

Table  3.  Condition  Table  for  Safety  Injection. 


a  function  of  the  current  mode  and  the  monitored  variable  WaterPres.  Table  2 
is  an  event  table  describing  the  term  Overridden  as  a  function  of  Pressure, 
Block,  and  Reset.  Table  3  is  a  condition  table  describing  the  controlled  variable 
Safety  Injection  as  a  function  of  Pressure  and  Overridden.  Table  3  states, 
“If  Pressure  is  High,  or  Permitted,  or  if  Pressure  is  TooLow  and  Overridden 
is  true,  then  Safety  Injection  is  Off;  if  Pressure  is  TooLow  and  Overridden 
is  false,  then  Safety  Injection  is  On.”2 


3  SCR  Requirements  Model 

To  provide  a  formal  foundation  for  tools  analyzing  the  specifications  and  simu¬ 
lating  system  execution  [7,  6],  we  have  developed  a  discrete  version  of  the  Four 
Variable  Model,  called  the  SCR  requirements  model  [8].  The  SCR  model  rep¬ 
resents  a  system  as  a  finite  state  machine  and  each  monitored  and  controlled 
quantity  as  a  discrete  variable.  Presented  below  are  excerpts  from  the  definition 
of  the  formal  model  [8]  and  a  description  of  the  interpretation  of  the  REQ  and 
NAT  relations  within  the  SCR  model. 

3.1  Summary  of  the  SCR  Model 

Entities  and  Types.  We  require  the  following  sets. 

—  MS  is  the  union  of  N  nonempty,  pairwise  disjoint  sets,  M\,  M2,  ■  ■  ■  ,  Mn ,  called 
mode  classes. 

—  TS  is  a  union  of  data  types,  where  each  type  is  a  nonempty  set  of  values.3 

—  VS  is  a  set  of  entity  values  with  VS  =  MS  U  TS. 

—  RF  is  a  set  of  entity  names  r,  which  is  partitioned  into  the  set  of  mode  names  MR, 

the  set  of  monitored  variable  names  IR,  the  set  of  term  names  GR,  and  the  set  of 

controlled  variable  names  OR.  For  all  r  £  RF,  TY(r)  C  VS  is  the  type  (i.e. ,  the 
set  of  possible  values)  of  entity  r. 

System  State  and  Conditions.  A  system  state  s  is  a  function  that  maps 
each  entity  name  r  in  RF  to  a  value.  That  is,  for  all  r  £  RF:  s(r)  =  v,  where 
v  £  TY(r).  Conditions  are  logical  propositions  defined  on  entities  in  RF. 

2  The  notation  “@T(Inmode)”  in  a  row  of  an  event  table  describes  system  entry  into 
the  group  of  modes  in  that  row. 

3  For  example,  the  type  “nonnegative  integers”  is  the  set  A f  =  {0,  1,2,..  .},  the  type 
Boolean  is  the  set  B  =  {true,  false},  etc. 


System  and  Events.  A  system  is  a  state  machine  whose  transition  from  one 
state  to  the  next  is  triggered  by  special  events,  called  monitored  events.  More 
precisely,  a  system,  E,  is  a  4-tuple  S  =  (Em ,  S,  so,T),  where 

—  Em  is  a  set  of  monitored  events.  A  primitive  event  is  denoted  as  @T(r  =  v), 
where  r  £  RF  is  an  entity  and  v  £  TY(r).  A  monitored  event  is  a  primitive  event 
@T(r  =  v),  where  r  £  IR  is  a  monitored  variable. 

—  S  is  the  set  of  possible  system  states. 

—  so  is  a  special  state  called  the  initial  state. 

—  T  is  the  system  transform,  a  function  from  Em  x  S  into  S. 

In  addition  to  denoting  primitive  events,  the  “@T”  notation  also  denotes 
conditioned  events.  A  simple  conditioned,  event  is  expressed  as 

@T(c)  WHEN  d, 

where  @T(c)  is  any  event  (i.e. ,  a  change  in  a  state  variable)  and  d  is  a  simple 
condition  or  a  conjunction  of  simple  conditions.  A  conditioned  event  e  is  a  logi¬ 
cal  proposition  composed  of  simple  conditioned  events  connected  by  the  logical 
connectors  A  and  V.  The  proposition  represented  by  a  simple  conditioned  event 
is  defined  by 

@T(c)  WHEN  d  =  NOT  c  Ac' Ad, 

where  the  unprimed  version  of  c  represents  c  in  one  state  (the  old  state)  and  the 
primed  version  of  c  represents  c  in  another  state  (the  new  state). 

System  History  Associated  with  every  monitored  variable  r  £  IR  is  a  set  of 
ordered  pairs  Vr , 


Vr  =  {(v,  v')  \v^v/,ve  TY(r),  v'  £  TY(r)}, 

that  defines  all  possible  transitions  of  r  and  that  contains  r’s  initial  value.  A 
monitored  event  @T(r  =  vr)  is  enabled  in  state  s  if  (s(r),  vr)  £  Vr.  A  history  II 
of  a  system  is  a  function  from  the  set  of  nonnegative  integers  Af  to  Em  x  S  such 
that  (1)  the  second  element  of  17(0)  is  s o,  (2)  for  all  n  £  Af,  if  I7(n)  =  (e,  s),  then 
e  is  enabled  in  s,  and  (3)  for  all  n  £  Af,  if  II (n)  =  (e,  s)  and  II  (n  +  1)  =  (e1 ,  s'), 
then  T(e,  s)  =  s' . 

Ordering  the  Entities.  Given  an  input  event  e  in  Em ,  states  s  and  s'  in  S, 
and  T(e,  s)  =  s' ,  the  value  of  each  entity  r  in  state  s'  may  depend  on  any  entity 
in  the  old  state  s  but  on  only  some  entities  in  the  new  state  s' .  To  describe  the 
dependencies  of  any  entity  r  £  RF  on  entities  in  the  new  state,  we  order  the 
entities  in  RF  as  a  sequence  R, 

R  =  <ri,r2,  .  .  .,r/,r/+i,  .  .  ,,rK,rK+1,  ...,rP>, 

where  <  rq,  r2,  .  .  . ,  r/  >,  r;  £  IR,  is  the  subsequence  of  monitored  variables, 
<  r/_|_i ,  r/+2,  .  .  . ,  tk  >,  r'i  £  GRU  MR,  is  the  subsequence  containing  terms  and 
modes,  and  <  r/y+i,  A/f+2,  .  .  . ,  rp  >,  r;  £  OR  is  the  subsequence  of  controlled 
variables. 


Modes 

Conditions 

mi 

Cl,l 

Cl, 2 

Cl  ,p 

m2 

C2,l 

C  2,2 

to 

mn 

Cn,  1 

Cn,  2 

Cn  ,p 

Ti 

Vl 

V2 

Vp 

Table  4.  Typical  Format  for  a  Condition  Table. 


The  entities  ry  E  R  are  partially  ordered  so  that  for  all  i,  i' ,  i  >  I,  1  <  i'  <  K, 
the  value  of  entity  ry  in  any  state  s  can  only  depend  on  the  value  of  entity  ry<  in 
the  same  state  s  if  i'  <  i.  This  definition  reflects  the  fact  that  each  monitored 
variable  can  only  be  changed  by  external  events  and  cannot  depend  on  the  other 
entities  in  R.  In  contrast,  each  term  in  s  can  depend  on  the  monitored  variables, 
the  modes,  or  other  terms  in  s.  Similarly,  each  mode  in  s  can  depend  on  the 
monitored  variables,  the  terms,  or  other  modes  in  s.  Finally,  each  controlled 
variable  in  s  can  depend  on  any  entity  that  precedes  it  in  the  sequence  R. 

Computing  the  Transform  Function.  Each  controlled  variable,  term,  and 
mode  class  ry  E  RF\  IR  is  defined  by  a  function  F{.  The  transform  function  T 
computes  the  new  state  by  composing  the  Fi  s.  In  an  SCR  requirements  speci¬ 
fication,  most  of  the  Fi  s  are  described  by  tables. 

Table  4  shows  a  typical  format  for  one  class  of  tables,  condition  tables.  A 
condition  table  describes  an  output  variable  or  term  ry  as  a  relation  pi, 

Pi  =  {{mj,  cj,k,  Vk)  e  Mp,(i)  x  Ci  x  TY(ri )  I  1  <  j  <  n,  1  <  k  <  p}, 

where  C'i  is  a  set  of  conditions  defined  on  entities  in  RF  and  is  the  mode 

class  associated  with  ry.  The  relation  pi  must  satisfy  the  following  properties: 

1.  The  mj  and  the  Vk  are  unique. 

2.  U "-jiiij  =  Mpp  (All  modes  in  the  mode  class  are  included). 

3.  For  all  j:  V^-1c-ltk  =  true  (Coverage:  The  disjunction  of  the  conditions  in  each 
row  of  the  table  is  true). 

4.  For  all  j,  k,l,  k  ^  l:  cJtk  A  chi  =  false  (Disjointness:  The  pairwise  conjunction  of 
the  conditions  in  each  row  of  the  table  is  always  false). 

Given  these  properties,  we  can  show  that  pi  is  a  function,  which  can  be  expressed 
as:  for  all  j,k,  1  <  j  <  n,  1  <  k  <  p,  pi(mj ,  cyj,)  =  v^. 

To  make  explicit  entity  r8’s  dependencies  on  other  entities,  we  consider  an 
alternate  form  Fi  of  the  function  pi.  To  define  Fi,  we  require  the  new  state  depen¬ 
dencies  set,  {yip,  yip,  ■  ■  ■ ,  where  yip  is  the  entity  name  for  the  associated 

mode  class  and  for  all  j,  2  <  j  <  rp,  yij  appears  in  some  condition  c  in  C\. 


Based  on  this  set  and  pi ,  we  define  F{  as 


F,(y,,i,  yi, 2,  ■  ■  ■ ,  y,,n,)  =  < 


vi  if  (yi, i  =m i  A  ci,i)  V  ...  V  (y,tl  =  mn  A  c„, i) 
«2  if  (yi, i  =mi  A  ci,2)  V  ...  V  («/;,!  =  m„  A  c„,2) 


(  vp  if  («/;,i  =m i  A  ci,p)  V  ...  V  («/;,i  =m„  A  c„,p). 


The  four  properties  guarantee  that  F{  is  a  total  function. 


3.2  The  SCR  Model,  REQ,  and  NAT 

NAT.  In  the  SCR  model,  NAT  models  the  behavior  of  the  monitored  and 
controlled  quantities.  Consider  the  monitored  variable  Block  in  the  example 
above  and  let  mi  =  Block.  The  type  definition  of  mi  is  TY(mj)  =  {Oil,  On} 
and  the  possible  changes  of  mi  from  one  state  to  the  next  are  defined  by 
Vmi  =  {(Off,  On),  (On,  Off)};  that  is,  Block  can  change  from  Off  to  On  or 
from  On  to  Off.  Similarly,  for  the  monitored  variable  m2  =  Reset  and  the  con¬ 
trolled  variable  ci  =  Saf etylnj ection,  TY(m2)  =TY(ci)  =  {Off,  On}  and 
Vm2  =  Vei  =  {(Off,  On),  (On,  Off)}. 

The  current  SCR  model  describes  all  monitored  and  controlled  quantities, 
even  those  which  are  naturally  continuous,  as  discrete  variables.  Doing  so  allows 
us  to  represent  the  system  as  a  finite  state  machine.  This  representation  facili¬ 
tates  formal  analysis  of  the  specifications  and  symbolic  execution  of  the  system 
via  simulation.  For  example,  to  model  WaterPres  as  a  discrete  variable,  we  as¬ 
sign  m3  =  WaterPres  the  type  definition  TY (m3)  =  {14,  15,  .  .  .,2000},  that  is, 
m3  is  any  integer  between  14  and  2000.  We  constrain  changes  in  WaterPres  by 
requiring  that  WaterPres  can  change  from  one  state  to  the  next  by  no  more 
than  1  psi,  that  is, 

|s'(m3)  -  s(m3)|  E  {0,  1}, 

where  s  and  s'  are  any  two  consecutive  states.  This  assumption  implies  the 
statement  in  Section  2.2  that  the  mode  class  Pressure  cannot  transition  directly 
from  TooLow  to  High,  or  from  High  to  TooLow.  Similarly,  we  can  define  the  type 
of  controlled  variable  C2  =  DisplayPres  as  TY (c 2)  =  {14,  15,  .  .  . ,  2000}  and 
constrain  changes  in  C2  by  requiring  that,  if  s  and  s'  are  any  two  consecutive 
states,  then  |s,(c2)  —  s(c2)|  E  {0,  1}. 

Ideal  Behavior.  In  the  SCR  model,  the  transform  function  T  defines  the  ideal 
system  behavior.  As  noted  above,  T  computes  the  new  state  from  an  event  and 
the  current  state  by  composing  the  functions  F{  that  define  the  values  of  terms, 
mode  classes,  and  controlled  variables.  Clearly,  reasoning  about  the  ideal  system 
behavior  using  T  abstracts  away  timing  delays  and  imprecision. 

4  Extending  the  SCR  Model  to  Hybrid  Systems 

To  use  the  SCR  model  to  specify  and  to  reason  about  hybrid  systems,  we  need 
to  extend  the  model  in  two  ways: 


—  Each  monitored  quantity  and  controlled  quantity  that  is  naturally  continuous 
is  represented  by  a  continuous  (rather  than  a  discrete)  variable. 

—  The  allowable  system  behavior  is  defined  by  associating  timing  and  accuracy 
requirements  with  each  controlled  variable. 


4.1  Adding  Continuous  Variables 

As  an  example,  consider  the  monitored  variable  m3  =  WaterPres  and  the  con¬ 
trolled  variable  C2  =  DisplayPres.  We  can  define  m3  as  a  real  number  between 
14.0  and  2000.0,  that  is,  TY(ms)  =  {x  \  x  £  R+  A  14.0  <  x  <  2000.0}.  Physical 
laws  (part  of  NAT)  bound  the  rate  at  which  m3  can  change.  To  express  this 
bound,  we  may  state  in  the  specification  that,  in  any  time  interval  of  length  0.1 
seconds,  the  maximum  change  in  the  value  of  WaterPres  is  0.03  psi;  that  is, 

| -  m3(t) |  <  .03, 

when  t'  —  t  =  0.1  sec.  The  constraints  on  c3  may  be  defined  in  a  similar  way. 
Clearly,  the  bounds  can  be  expressed  by  more  complex  functions,  e.g.,  by  contin¬ 
uously  differentiable  functions,  by  piecewise  continuous  functions,  or  by  bounded 
derivatives. 

We  note  that  any  reasoning  that  used  the  discrete  models  of  WaterPres 
and  DisplayPres  to  analyze  system  behavior  should  be  reevaluated  to  make 
sure  the  reasoning  is  still  valid  when  more  accurate  models  of  these  two  natu¬ 
rally  continuous  quantities  are  used.  This  is  especially  important  when  discrete 
approximations  of  continuous  quantities  are  used  in  verifying  critical  system 
properties. 

4.2  Adding  Time 

The  SCR  model  introduced  in  Section  3.1  is  untimed.  Thus  if  an  event  occurs 
in  state  s  that  changes  a  controlled  variable,  we  assume  that  the  next  state  s' 
reflects  the  change  in  the  controlled  variable  (as  well  as  changes  in  the  monitored 
variable  that  triggered  the  new  state  and  any  resulting  changes  in  mode  classes, 
terms,  and  other  controlled  variables).  To  add  time  to  the  SCR  model,  we  adapt 
the  approach  developed  by  Lynch  and  Vaandrager  [11]  for  timed  automata.  This 
approach  associates  each  event  in  a  state  history  with  a  time.  More  precisely, 
for  each  state  history,  s 0,  (ei,  si),  (e2,  S2),  •  •  .,  we  define  a  sequence  of  the  form 
(ei ,  ti),  (e2,  t'2),  •  •  .,  where  each  e8-  is  either  a  monitored  event  or  an  event  changing 
the  value  of  a  controlled  variable  and  each  C  is  a  non-negative  real- valued  time. 
We  require  that,  for  all  i,  i  +  1,  C'+i  >  ti  and  define  a  function  TIME  that  maps 
each  event  e  in  a  system  history  to  a  time  t,  that  is,  TIME(e)  =  t. 


4.3  Specifying  the  Actual  System  Behavior 

To  specify  the  allowable  system  behavior,  we  associate  timing  and  accuracy 
requirements  with  each  controlled  variable.  Consider,  for  example,  the  controlled 


variable  DisplayPres  in  the  example,  and  let  C2  =  DisplayPres.  To  specify 
the  constraints  on  C2,  we  must  state  the  degree  of  accuracy  that  is  required 
in  the  displayed  value  of  WaterPres.  For  example,  we  may  require  that  the 
displayed  value  of  WaterPres  at  any  given  t  is  within  0.1  psi  of  the  actual  value 
of  WaterPres  at  time  t,  that  is,  \c2(t)  —  ms(t)\  <  0.1  psi. 

Consider  a  system  design  that  uses  a  given  input  device  to  measure  WaterPres, 
a  given  output  device  to  write  the  value  of  WaterPres  to  the  display,  and  spe¬ 
cific  hardware  and  software.  Then,  the  maximum  rate  at  which  WaterPres  can 
change  in  a  given  time  interval  (defined  by  NAT),  the  degree  of  accuracy  and 
timing  delays  associated  with  the  input  and  output  devices  (defined  by  IN  and 
OUT),  and  the  system  delay  in  reading  from  and  writing  to  the  devices  together 
determine  whether  the  required  accuracy  can  be  achieved. 

To  specify  the  requirements  for  turning  the  safety  injection  system  on  and  off, 
we  must  specify  timing  constraints  on  the  controlled  variable  Saf  etylnj  ection. 
Let  ci  represent  Saf  etylnj  ection.  Suppose  that  the  safety  injection  system 
must  be  turned  on  within,  say,  0.2  seconds  after  the  occurrence  of  the  triggering 
event  (e.g.,  WaterPres  drops  below  Low  when  Overridden  =  false).  Then,  if  the 
triggering  event  e*  occurs  at  time  t,  that  is,  TIME(efc)  =  t,  the  event  e^+j  that 
turns  on  Saf  etylnj  ection  must  occur  within  the  time  interval  [t,t+  0.2],  that 
is,  TIME(ej,_|_j)  £  [t,t  +  0.2].  By  considering  a  particular  system  design — that 
is,  the  timing  delays  and  degree  of  accuracy  of  the  input  and  output  devices 
and  computer  hardware  and  software  that  control  safety  injection — we  can  com¬ 
pute  whether  safety  injection  will  always  be  activated  within  the  required  time 
interval. 

5  Summary 

We  have  presented  several  examples  to  show  how  the  SCR  requirements  model 
can  be  extended  to  specify  and  to  reason  about  hybrid  systems.  The  next  step 
is  to  extend  the  formal  definition  of  the  SCR  model  to  include  continuous  vari¬ 
ables,  time,  and  accuracy.  By  adding  such  information  to  system  and  software 
requirements  specifications,  we  can  provide  precise  guidance  to  the  developers  of 
computer  systems  and  a  formal  foundation  for  analyzing  the  behavior  of  these 
systems. 
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